분산 SQL 데이터베이스 TiDB

1. NewSQL과 HTAP 시대의 데이터베이스, TiDB의 등장

1.1 현대 데이터베이스 환경의 도전 과제

현대 디지털 비즈니스 환경은 데이터의 폭발적인 증가와 실시간 처리 요구라는 두 가지 거대한 흐름에 직면해 있다. 이러한 변화는 기존 데이터베이스 아키텍처에 근본적인 도전 과제를 제기한다. 전통적인 관계형 데이터베이스 관리 시스템(RDBMS)은 수십 년간 데이터 관리의 표준으로 자리 잡아 왔으나, 데이터의 양이 기하급수적으로 증가하고 동시 사용자 접속 요구가 높아짐에 따라 명백한 확장성(scalability)의 한계에 부딪혔다.1 RDBMS가 주로 채택하는 수직적 확장(vertical scaling), 즉 단일 서버의 CPU, 메모리, 스토리지 성능을 높이는 방식은 고비용 구조를 야기할 뿐만 아니라, 하드웨어 성능 향상에 물리적 제약이 따르기 때문에 무한정 지속될 수 없다.1

이러한 RDBMS의 확장성 문제를 해결하기 위해 등장한 NoSQL 데이터베이스는 수평적 확장성, 즉 여러 대의 서버를 클러스터로 묶어 성능과 용량을 늘리는 방식을 통해 대규모 데이터를 효과적으로 처리하는 능력을 보여주었다. 하지만 대부분의 NoSQL 시스템은 확장성을 확보하는 과정에서 데이터의 강한 일관성(strong consistency)과 ACID(원자성, 일관성, 고립성, 지속성) 트랜잭션 보장을 완화하는 타협을 선택했다.4 이는 데이터의 정합성이 비즈니스의 성패를 좌우하는 금융 거래, 결제 시스템, 재고 관리와 같은 핵심적인 시나리오에 NoSQL을 적용하기 어렵게 만드는 근본적인 한계로 작용했다.6

더불어, 기업들은 온라인 트랜잭션 처리(OLTP, Online Transactional Processing)와 온라인 분석 처리(OLAP, Online Analytical Processing)라는 상이한 두 가지 워크로드를 처리해야 하는 과제를 안고 있다. 전통적으로 이 두 워크로드는 각각에 최적화된 별도의 시스템으로 분리하여 운영되었다. OLTP 데이터는 주기적으로 ETL(Extract, Transform, Load)이라는 데이터 추출, 변환, 적재 과정을 거쳐 OLAP 시스템(주로 데이터 웨어하우스)으로 옮겨졌다. 그러나 이 방식은 데이터 파이프라인의 아키텍처를 복잡하게 만들고, ETL 프로세스에 소요되는 시간으로 인해 데이터 지연(latency)을 발생시켜 실시간 데이터에 기반한 신속한 의사결정을 저해하는 심각한 단점을 내포하고 있다.4

이러한 기술적 배경은 데이터베이스 패러다임의 근본적인 변화를 요구하게 되었다. 과거 데이터베이스 아키텍처 선택은 ‘확장성’(NoSQL)과 ‘일관성’(RDBMS) 사이의 트레이드오프, 그리고 ‘트랜잭션 처리’(OLTP)와 ‘분석 처리’(OLAP) 시스템의 분리라는 이분법적 타협을 강요했다. TiDB의 등장은 바로 이러한 기술적 타협의 종식을 목표로 하는 새로운 흐름을 반영한다. NewSQL이라는 개념 자체가 RDBMS의 신뢰성과 NoSQL의 확장성이라는 두 마리 토끼를 모두 잡으려는 시도이며, HTAP(Hybrid Transactional/Analytical Processing)는 트랜잭션과 분석의 경계를 허물어 데이터 아키텍처를 통합하려는 움직임이다. 따라서 TiDB의 핵심 정체성은 단순히 새로운 데이터베이스의 출현이 아니라, 기존 패러다임이 강요했던 기술적 제약을 근본적으로 해결하려는 아키텍처적 철학의 구현체로 이해해야 한다. 이는 기업이 비즈니스 요구사항을 기술적 한계에 맞추는 것이 아니라, 기술이 비즈니스의 역동적인 요구사항을 온전히 지원할 수 있게 되는 패러다임의 전환을 의미한다.

1.2 TiDB의 정의 및 포지셔닝

이러한 시대적 요구에 부응하여 등장한 TiDB는 PingCAP사에 의해 개발된 오픈소스 분산 SQL 데이터베이스이다.10 TiDB는 NewSQL 패러다임을 충실히 따르며, 관계형 데이터베이스의 핵심 가치인 ACID 트랜잭션 보장과 NoSQL 데이터베이스의 가장 큰 장점인 수평적 확장성을 하나의 시스템 안에서 동시에 구현하는 것을 목표로 한다.4

TiDB의 가장 중요한 특징 중 하나는 MySQL 프로토콜과의 높은 호환성이다. MySQL 5.7 및 8.0 버전의 공통 기능과 구문을 지원하도록 설계되어, 기존에 MySQL을 사용하던 애플리케이션과 생태계 도구들을 대부분 코드 변경 없이, 혹은 최소한의 수정만으로 TiDB로 마이그레이션할 수 있다.6 이는 새로운 데이터베이스 기술 도입 시 발생하는 가장 큰 장벽인 학습 곡선, 기존 시스템과의 통합 문제, 생태계 부재를 효과적으로 해결하는 핵심 전략이다. 개발자들은 익숙한 SQL 구문, 드라이버, ORM 프레임워크, GUI 도구를 그대로 활용할 수 있어 도입 저항을 최소화할 수 있다.14 이는 수십 년간 축적된 방대한 MySQL 생태계의 이점을 그대로 활용하면서 분산 데이터베이스의 장점을 누릴 수 있게 하는 실용적인 접근 방식이다.

TiDB가 제시하는 핵심 가치 제안은 HTAP(Hybrid Transactional/Analytical Processing)이다.16 이는 단일 데이터베이스 시스템 내에서 OLTP 워크로드와 OLAP 워크로드를 동시에, 그리고 효율적으로 처리하는 것을 의미한다.1 TiDB는 행(row) 기반 스토리지 엔진인 TiKV와 열(column) 기반 스토리지 엔진인 TiFlash를 함께 사용하여 이를 구현한다. 이 아키텍처를 통해 기업은 복잡한 ETL 파이프라인 없이 트랜잭션이 발생하는 바로 그 데이터에 대해 실시간으로 복잡한 분석 쿼리를 수행할 수 있게 된다. 결과적으로 데이터 아키텍처가 단순화되고, 데이터의 최신성(freshness)이 보장되며, 비즈니스 인텔리전스(BI) 및 의사결정의 속도가 획기적으로 향상된다.18

2. TiDB 분산 아키텍처 해부

TiDB의 강력한 확장성과 유연성은 그 독창적인 분산 아키텍처에 기인한다. 전통적인 모놀리식 데이터베이스와 달리, TiDB는 주요 기능들을 독립적인 컴포넌트로 분리하고, 이들이 유기적으로 상호작용하도록 설계되었다.

2.1 컴퓨팅과 스토리지의 분리

TiDB 아키텍처의 가장 근본적인 설계 철학은 컴퓨팅 계층(computing layer)과 스토리지 계층(storage layer)의 분리이다.1 이는 데이터베이스 시스템을 구성하는 두 가지 핵심 자원, 즉 SQL 처리 능력과 데이터 저장 능력을 독립적으로 관리하고 확장할 수 있게 함을 의미한다.

이러한 아키텍처적 분리 덕분에, 클러스터는 워크로드의 특성에 따라 각 계층을 독립적으로, 그리고 서비스 중단 없이 온라인 상태에서 수평적으로 확장(scale-out)하거나 축소(scale-in)할 수 있다.6 예를 들어, 애플리케이션의 동시 접속자 수가 늘어나 SQL 처리량이 병목이 될 경우, 스토리지 용량은 그대로 둔 채 컴퓨팅 노드인 TiDB 서버만 추가하여 대응할 수 있다. 반대로, 데이터 저장량은 급증하지만 쿼리 요청은 많지 않은 아카이빙 시나리오에서는 TiDB 서버는 최소한으로 유지하고 스토리지 노드인 TiKV 서버만 증설하면 된다.

이러한 유연성은 전통적인 데이터베이스가 컴퓨팅과 스토리지가 강하게 결합되어 있어 둘 중 하나의 자원만 부족해도 전체 서버를 값비싸게 업그레이드해야 했던 비효율성을 근본적으로 해결한다. 더 나아가, HTAP 시나리오에서는 OLTP 워크로드를 처리하는 TiKV와 OLAP 워크로드를 처리하는 TiFlash를 물리적으로 다른 서버에 배포함으로써 워크로드 간의 자원 경합을 원천적으로 차단할 수 있다.17 이처럼 TiDB의 아키텍처는 기업이 실제 워크로드 패턴에 맞춰 자원을 마치 레고 블록처럼 유연하고 경제적으로 구성할 수 있게 해주는, 비용과 성능 최적화의 핵심적인 기반을 제공한다.

2.2 TiDB 서버: 상태 비저장(Stateless) SQL 컴퓨팅 계층

TiDB 서버는 클러스터의 컴퓨팅 계층을 담당하며, 클라이언트 애플리케이션의 접점 역할을 한다. 이 계층의 노드들은 자체적으로 데이터를 저장하지 않는 상태 비저장(stateless) 구조로 설계되어 있어 높은 확장성과 유연성을 제공한다.21

주요 역할은 다음과 같다:

• MySQL 프로토콜 엔드포인트: 클라이언트로부터 MySQL 프로토콜 기반의 연결 요청을 받아 처리한다. 따라서 기존 MySQL용 드라이버나 커넥터, 관리 도구를 그대로 사용하여 TiDB 클러스터에 접속할 수 있다.21
• SQL 처리: 수신된 SQL 쿼리에 대해 파싱, 유효성 검사, 쿼리 계획 수립 및 최적화 과정을 수행한다.14 TiDB의 비용 기반 옵티마이저(Cost-Based Optimizer)는 테이블과 인덱스의 통계 정보를 활용하여 가장 효율적인 데이터 접근 경로를 결정하고, 분산 환경에 최적화된 실행 계획을 생성한다.
• 분산 실행: 생성된 실행 계획에 따라 실제 데이터가 저장된 스토리지 계층(TiKV 또는 TiFlash)으로 데이터 읽기/쓰기 요청을 전달한다. 이후 스토리지 노드들로부터 반환된 결과를 취합하고 최종적으로 클라이언트에게 응답을 보낸다.21

TiDB 서버는 상태를 저장하지 않기 때문에, 로드 밸런서(예: LVS, HAProxy, F5 또는 TiDB가 제공하는 TiProxy) 뒤에 여러 개의 TiDB 서버 인스턴스를 배치하는 방식으로 간단하게 수평 확장이 가능하다.21 SQL 처리 능력이 부족해지면 새로운 TiDB 서버 인스턴스를 추가하기만 하면 되며, 이 과정은 기존 서비스에 영향을 주지 않는다.

2.3 스토리지 계층

TiDB의 스토리지 계층은 실제 데이터가 영속적으로 저장되는 곳으로, 워크로드 특성에 따라 최적화된 두 종류의 스토리지 엔진으로 구성된다.

2.3.1 TiKV 서버: OLTP 워크로드를 위한 분산 트랜잭션 Key-Value 저장소

TiKV 서버는 TiDB의 핵심 스토리지 엔진으로, 온라인 트랜잭션 처리(OLTP) 워크로드에 최적화된 분산 트랜잭셔널 Key-Value 저장소이다.14

• Key-Value 데이터 모델: TiDB의 테이블 데이터(행과 열)는 내부적으로 Key-Value 쌍으로 변환되어 TiKV에 저장된다. Key는 테이블 ID, 행 ID(RowID) 또는 인덱스 값 등을 조합하여 고유하게 생성되며, Value는 해당 행의 실제 데이터를 담는다.23 이러한 구조는 데이터의 분산 저장을 용이하게 한다.
• Region: TiKV는 전체 Key-Value 공간을 ’Region’이라는 논리적인 단위로 분할하여 관리한다.22 Region은 데이터 이동과 복제의 기본 단위이며, 기본적으로 약 96MB의 크기 제한을 가진다.21 데이터가 증가하여 Region의 크기가 임계값을 초과하면 자동으로 두 개의 작은 Region으로 분할된다.
• Raft 기반 복제: 데이터의 고가용성과 강한 일관성을 보장하기 위해, 각 Region의 데이터는 Raft 합의 알고리즘을 통해 여러 TiKV 노드에 복제된다 (기본 3개의 복제본).8 이 복제본들은 하나의 Raft 그룹을 형성하며, 이 중 하나가 Leader, 나머지가 Follower 역할을 수행한다. 모든 읽기/쓰기 요청은 Leader를 통해 처리된다.
• 분산 트랜잭션: Google의 Percolator 트랜잭션 모델에 기반하여 여러 Region과 노드에 걸친 분산 트랜잭션을 완벽하게 지원하며, ACID 속성을 보장한다.7
• 로컬 스토리지 엔진: 각 TiKV 노드는 로컬 디스크에 데이터를 저장하기 위해 고성능 임베디드 스토리지 엔진인 RocksDB를 사용한다.8

2.3.2 TiFlash 서버: OLAP 워크로드를 위한 실시간 컬럼 기반 저장소

TiFlash 서버는 TiDB의 하이브리드 트랜잭션/분석 처리(HTAP) 아키텍처를 완성하는 핵심 구성요소로, 분석(OLAP) 워크로드에 특화된 컬럼 기반(columnar) 스토리지 엔진이다.16

• 컬럼형 스토리지: 데이터를 행 단위가 아닌 열 단위로 저장한다. 이 방식은 특정 열에 대한 집계나 스캔이 주로 발생하는 분석 쿼리에서 불필요한 데이터 I/O를 줄여 성능을 극적으로 향상시킨다.20
• Raft Learner를 통한 데이터 복제: TiFlash는 TiKV의 데이터를 비동기적으로 복제한다. 이때 Raft 그룹의 정식 멤버(Follower)가 아닌 ’Learner’라는 특별한 역할을 수행한다.4 Learner는 Raft 그룹의 의사결정(투표)에 참여하지 않으므로, TiFlash 노드의 장애나 네트워크 지연이 TiKV의 OLTP 트랜잭션 커밋 과정에 영향을 주지 않는다.14 이는 HTAP 구현의 가장 큰 난제인 OLTP와 OLAP 워크로드 간의 간섭을 효과적으로 해결하는 우아한 기술적 해법이다.
• 지능형 선택: TiDB 옵티마이저는 쿼리의 비용을 분석하여, OLTP성 쿼리는 TiKV에서, OLAP성 쿼리는 TiFlash에서 데이터를 읽도록 지능적으로 실행 계획을 수립한다. 경우에 따라서는 하나의 쿼리 내에서 TiKV와 TiFlash 양쪽의 데이터를 모두 활용하기도 한다.27
• 아키텍처 확장: TiDB v7.0.0부터는 TiFlash가 스토리지와 컴퓨팅을 분리하고 Amazon S3와 같은 저비용 객체 스토리지에 데이터를 저장하는 아키텍처를 지원하여, 대규모 분석 환경의 비용 효율성을 크게 향상시켰다.29

2.4 Placement Driver (PD): 클러스터의 두뇌

Placement Driver(PD)는 전체 TiDB 클러스터를 총괄하는 관리 및 스케줄링 컴포넌트로, 클러스터의 ‘두뇌’ 역할을 수행한다.21 분산 시스템의 복잡성은 노드 추가/삭제, 데이터 불균형, 핫스팟 발생 시 운영자의 수동 개입을 요구하는 데서 비롯되는데, TiDB는 이 복잡성을 PD를 통해 자동화한다.

• 메타데이터 저장: 클러스터의 모든 메타데이터를 중앙에서 관리한다. 가장 중요한 정보는 각 Region의 위치 정보, 즉 어떤 Key-Value 범위(Region)가 어느 TiKV 노드에 저장되어 있는지에 대한 실시간 매핑 정보다. TiDB 서버가 쿼리를 실행할 때 이 정보를 PD로부터 받아와야 올바른 TiKV 노드로 요청을 보낼 수 있다.14
• 타임스탬프 오라클(TSO) 할당: 분산 트랜잭션의 순서를 정하고 동시성을 제어하기 위해, 전역적으로 유일하고 단조롭게 증가하는 타임스탬프(Timestamp)를 할당하는 TSO(Timestamp Oracle) 역할을 수행한다.14
• 데이터 스케줄링: PD는 클러스터의 ’자율 신경 시스템’처럼 동작한다. 각 TiKV 노드로부터 주기적으로 디스크 사용량, I/O 부하, Region 수 등의 상태 정보를 수집(heartbeat)한다.31 이 정보를 바탕으로 클러스터의 균형을 유지하기 위한 다양한 스케줄링 작업을 자동으로 수행한다.
• 로드 밸런싱: 특정 노드에 데이터나 부하가 집중되면, 해당 노드의 Region을 다른 한가한 노드로 자동으로 이동시켜 부하를 분산시킨다.32
• Region 분할 및 병합: Region의 크기가 너무 커지면 자동으로 분할하고, 반대로 너무 작고 인접한 Region들은 병합하여 관리 효율성을 높인다.22
• 장애 복구: 특정 TiKV 노드에 장애가 발생한 것을 감지하면, 해당 노드에 있던 Region들의 복제본을 다른 정상 노드에 자동으로 생성하여 데이터의 가용성과 복제 수준을 유지한다.32
• 고가용성: PD 자체도 단일 장애 지점(SPOF)이 되지 않도록, 내부적으로 etcd를 활용한 Raft 알고리즘 기반의 클러스터로 구성된다 (일반적으로 3개 또는 5개의 홀수 노드).21 이 중 하나의 Leader만이 실제 작업을 수행하고, 나머지는 Leader 장애 시 즉시 새로운 Leader를 선출할 수 있도록 대기한다.

이러한 구성요소들의 유기적인 결합을 통해 TiDB는 높은 수준의 확장성, 가용성, 그리고 HTAP 처리 능력을 갖춘 통합 데이터 플랫폼으로서의 면모를 완성한다.

3. 핵심 기술 메커니즘 분석

TiDB의 혁신적인 아키텍처는 몇 가지 핵심적인 기술 메커니즘에 의해 뒷받침된다. 이 메커니즘들은 TiDB가 어떻게 수평적 확장성, 고가용성, 분산 트랜잭션, 그리고 HTAP 워크로드 처리를 동시에 달성하는지를 설명한다.

3.1 수평적 확장성(Horizontal Scalability)의 구현

TiDB의 확장성은 이론적으로는 무한하지만, 그 실제 성능은 물리적 제약과 워크로드 패턴에 따라 달라지는 복잡한 함수 관계를 가진다. 마케팅 자료는 종종 ’무한한 수평 확장성’을 강조하지만, 실제 최고의 성능을 이끌어내기 위해서는 데이터 모델링, 트랜잭션 패턴, 네트워크 토폴로지 등 다양한 요소를 고려한 깊이 있는 최적화가 필수적이다. 예를 들어, AUTO_INCREMENT 기본 키를 사용하는 테이블에 대량의 INSERT가 발생하면, 새로운 데이터들이 특정 Region에 집중되어 해당 TiKV 노드가 병목이 되는 ‘쓰기 핫스팟’ 문제가 발생할 수 있다. TiDB는 이를 완화하기 위해 AUTO_RANDOM과 같은 기능을 제공하지만 33, 근본적으로는 스키마 설계 단계에서부터 데이터 분산을 고려해야 한다.

• 데이터 분할 단위 ‘Region’: TiDB 확장성의 근간은 TiKV가 전체 Key-Value 공간을 ’Region’이라는 관리하기 쉬운 작은 단위로 분할하는 방식에 있다.22 각 Region은 연속적인 Key 범위를 가지며, 기본적으로 96MB의 크기 제한을 가진다.34 데이터가 지속적으로 추가되어 Region의 크기가 이 임계값을 초과하면, TiKV는 해당 Region을 두 개의 새로운 Region으로 자동으로 분할(split)한다. 이 메커니즘은 데이터가 증가함에 따라 클러스터가 자연스럽게 확장될 수 있는 기반을 제공한다.
• 자동 샤딩(Auto-Sharding) 및 로드 밸런싱: TiDB는 수동 샤딩의 복잡성을 완전히 제거했다.2 PD는 클러스터 내 모든 TiKV 노드들의 부하 상태(디스크 공간, I/O, CPU 사용량 등)와 Region 분포를 지속적으로 모니터링한다.31 만약 특정 노드에 데이터가 편중되거나(hotspot) 부하가 집중되면, PD는 해당 노드의 Region들을 다른, 상대적으로 부하가 적은 노드로 자동으로 이동(migration)시키는 스케줄링 명령을 내린다.32 이 과정은 운영자의 개입 없이 투명하게 이루어지며, 클러스터 전체의 데이터와 부하를 항상 균등하게 유지한다.
• 컴퓨팅 및 스토리지 계층의 독립적 확장: 컴퓨팅과 스토리지의 분리 아키텍처 덕분에, 애플리케이션은 필요에 따라 특정 계층의 자원만 선택적으로 확장할 수 있다. 이 모든 확장 작업은 클러스터가 온라인 상태인 동안 서비스 중단 없이(downtime-free) 수행되며, 이 과정은 애플리케이션에 완전히 투명하게 진행된다.6

3.2 고가용성(High Availability)과 강력한 일관성(Strong Consistency)

TiDB의 고가용성은 시스템의 모든 계층에서 단일 장애 지점(Single Point of Failure, SPOF)을 제거하려는 체계적인 설계의 결과물이다. 스토리지 계층(TiKV/TiFlash)에서는 데이터의 기본 단위인 ‘Region’ 자체가 Raft 그룹을 통해 다중 복제되어 노드 장애에 내성을 가진다.40 관리 계층(PD)마저도 자체적으로 Raft 클러스터를 구성하여 PD 노드 장애에도 클러스터 관리가 중단되지 않도록 한다.21 상태 비저장인 컴퓨팅 계층(TiDB Server)은 로드밸런서 뒤에 다중으로 배치되어 개별 서버 장애에 대응한다.21 이처럼 TiDB는 특정 컴포넌트의 장애가 전체 시스템의 장애로 이어지지 않도록 모든 계층에서 다중화와 자동 장애 복구 메커니즘을 내장하고 있다.

• Raft 합의 알고리즘: TiDB는 데이터 복제와 일관성 유지를 위해 분산 합의 알고리즘인 Raft를 핵심 기술로 사용한다.8 각 Region의 복제본들은 하나의 Raft 그룹을 형성하며, 이 그룹 내에서 데이터의 모든 변경 사항(로그)이 일관되게 복제되도록 보장한다.25
• Multi-Raft 아키텍처: TiKV 클러스터는 수천, 수만 개의 Region을 가질 수 있으며, 이는 곧 수천, 수만 개의 독립적인 Raft 그룹이 동시에 운영됨을 의미한다. 이를 Multi-Raft 아키텍처라 부른다.4 각 Raft 그룹은 독립적으로 Leader를 선출하고 로그를 복제하므로, 클러스터 전체의 처리량을 효과적으로 확장할 수 있다.
• 쓰기 프로세스와 일관성 보장: 모든 쓰기 요청은 해당 데이터가 속한 Region의 Raft Leader를 통해서만 처리된다. Leader는 쓰기 요청을 로그(log) 형태로 변환하여 Follower들에게 전파한다. Raft 프로토콜에 따라, 과반수(majority)의 복제본(Leader 포함)이 해당 로그를 자신의 스토리지에 안전하게 저장했다고 응답한 후에야 해당 쓰기 작업은 ’커밋(committed)’된 것으로 간주되고, 클라이언트에게 성공 응답을 보낼 수 있다.6 이 메커니즘은 클러스터를 구성하는 노드 중 소수(예: 3개 중 1개)가 다운되더라도 데이터 유실 없이 강력한 일관성을 보장하는 핵심 원리이다.17
• 자동 장애 복구(Failover): Raft 그룹의 Leader 노드에 장애가 발생하거나 네트워크가 단절되면, 나머지 Follower 노드들은 정해진 시간(election timeout) 내에 이를 감지하고 새로운 Leader를 선출하는 절차를 자동으로 시작한다. 새로운 Leader가 선출되면 즉시 쓰기 요청을 처리하기 시작하므로, 서비스는 짧은 중단(일반적으로 수 초 이내) 후 자동으로 복구된다. 이 모든 과정은 애플리케이션에 투명하게 이루어진다.32

3.3 분산 ACID 트랜잭션

많은 분산 시스템이 CAP 이론에 따라 일관성(Consistency)을 완화하고 가용성(Availability)을 선택하는 반면, TiDB는 금융 서비스와 같은 미션 크리티컬 애플리케이션을 목표로 하므로 강력한 일관성과 ACID 보장을 최우선으로 한다.6 이를 위해 Google이 대규모 분산 시스템에서 ACID를 구현하기 위해 고안한 Percolator 모델을 채택했다.45 이 모델은 2단계 커밋과 MVCC를 결합하여 분산된 노드들 간에 트랜잭션의 원자성과 격리성을 보장한다. 물론 이 방식은 타임스탬프를 얻기 위해 PD에 접근해야 하는 등 지연 시간 측면에서 비용이 발생하지만 47, TiDB는 이 비용을 감수하고서라도 데이터 정합성을 지키겠다는 명확한 기술적 선택을 한 것이다.

• Google Percolator 트랜잭션 모델: TiDB는 Google의 Percolator 논문에서 영감을 받은 2단계 커밋(Two-Phase Commit, 2PC) 기반의 트랜잭션 모델을 채택하여 여러 노드에 분산된 데이터에 대한 ACID 트랜잭션을 지원한다.14
• MVCC(Multi-Version Concurrency Control): TiKV는 데이터를 덮어쓰는 대신, 각 데이터의 여러 버전을 타임스탬프와 함께 저장한다. 모든 트랜잭션은 PD로부터 고유한 시작 타임스탬프(start_ts)를 부여받는다. 읽기 작업은 이 start_ts를 기준으로, 해당 시점 이전에 커밋된 최신 버전의 데이터를 읽는다. 이 덕분에 읽기 작업은 쓰기 작업을 차단하지 않고(non-blocking reads), 특정 시점의 일관된 스냅샷을 제공받을 수 있다. TiDB의 기본 트랜잭션 격리 수준은 스냅샷 격리(Snapshot Isolation)이다.7
• 2단계 커밋(2PC) 프로세스:

1. Prewrite 단계: 트랜잭션을 커밋하기 위해, TiDB는 먼저 트랜잭션에 포함된 모든 Key-Value에 대해 ’Prewrite’를 시도한다. 이 과정에서 각 Key에 락(lock)을 걸고, 데이터를 임시로 기록한다. 트랜잭션에 포함된 Key 중 하나를 ’Primary Key’로 지정하고, 나머지는 ’Secondary Key’가 된다. Primary Key의 락에는 트랜잭션의 상태 정보가 담긴다.46
2. Commit 단계: 모든 Key에 대한 Prewrite가 성공하면, TiDB는 PD로부터 커밋 타임스탬프(commit_ts)를 받아 Primary Key에 커밋을 시도한다. 이는 Primary Key의 락을 해제하고, commit_ts와 함께 커밋 정보를 기록하는 작업이다. Primary Key가 성공적으로 커밋되면, 트랜잭션 전체가 성공한 것으로 간주하고 클라이언트에게 즉시 성공을 반환한다. 나머지 Secondary Key들은 이후 비동기적으로 커밋된다.45 만약 다른 트랜잭션이 커밋되지 않은 Secondary Key를 만나면, Primary Key의 상태를 확인하여 롤백하거나 커밋을 돕는다.

• 낙관적(Optimistic) 및 비관적(Pessimistic) 트랜잭션: TiDB는 기본적으로 커밋 시점에 충돌을 감지하는 낙관적 트랜잭션 모델을 사용한다. 이 모델은 충돌이 적은 환경에서 높은 성능을 보이지만, 충돌이 발생하면 트랜잭션을 재시도해야 하는 오버헤드가 있다.48 이러한 단점을 보완하기 위해, TiDB는 SELECT... FOR UPDATE 구문을 통해 트랜잭션 실행 단계에서 미리 락을 획득하는 비관적 트랜잭션 모델도 지원한다. 이는 충돌이 빈번한 워크로드에서 불필요한 재시도를 줄여 성공률을 높인다.48

3.4 HTAP 아키텍처의 작동 원리

HTAP의 가장 큰 기술적 과제는 분석(OLAP) 쿼리가 트랜잭션(OLTP) 성능에 미치는 영향을 최소화하면서, 동시에 분석 쿼리가 최신 데이터를 조회할 수 있도록 보장하는 것이다. TiDB는 이를 TiFlash와 독창적인 데이터 동기화 메커니즘을 통해 해결한다.

• 데이터 동기화: TiFlash 노드는 Raft 그룹의 ‘Learner’ 역할로 참여한다.4 Learner는 Raft 그룹의 일원이지만 투표권이 없기 때문에, 쓰기 트랜잭션의 커밋 과정에 관여하지 않는다. TiKV의 Raft Leader는 로그를 Follower들에게 복제하는 것과 동시에 Learner인 TiFlash에게도 비동기적으로 전송한다.27 이 방식 덕분에 TiFlash 노드의 상태와 관계없이 TiKV의 OLTP 트랜잭션은 지연 없이 처리될 수 있으며, 동시에 TiFlash는 거의 실시간에 가까운 데이터 신선도(freshness)를 유지할 수 있다.4
• 워크로드 격리: OLTP 쿼리는 행 기반 스토리지인 TiKV에서, OLAP 쿼리는 컬럼 기반 스토리지인 TiFlash에서 처리되도록 분리할 수 있다. TiKV와 TiFlash를 서로 다른 물리적 서버에 배포하면, CPU, 메모리, I/O 등 시스템 자원에 대한 경합이 원천적으로 차단된다. 이를 통해 무거운 분석 쿼리가 민감한 트랜잭션 처리 성능을 저해하는 것을 방지할 수 있다.4
• 지능형 쿼리 라우팅: TiDB의 옵티마이저는 쿼리를 실행하기 전에 테이블 통계 정보를 기반으로 비용 모델을 사용하여 최적의 실행 계획을 수립한다. 이 과정에서 옵티마이저는 쿼리의 특성을 분석하여 TiKV의 행 기반 데이터에 접근하는 것이 유리한지, TiFlash의 컬럼 기반 데이터에 접근하는 것이 유리한지를 판단한다. 예를 들어, 소수의 행을 조회하는 쿼리는 TiKV로, 특정 열에 대한 대규모 집계 쿼리는 TiFlash로 보내는 식이다. 때로는 하나의 쿼리 안에서도 일부는 TiKV에서, 일부는 TiFlash에서 데이터를 가져와 조인하는 복합적인 실행 계획을 생성하기도 한다.27
• MPP(Massively Parallel Processing): TiFlash는 대규모 분석 쿼리의 성능을 극대화하기 위해 MPP 아키텍처를 채택했다. 하나의 복잡한 쿼리가 들어오면, TiDB는 이를 여러 개의 작은 하위 작업으로 분할하여 여러 TiFlash 노드에 분산시킨다. 각 TiFlash 노드는 할당된 작업과 데이터를 병렬로 처리하고, 그 결과를 다시 취합하여 최종 결과를 도출한다. 이 방식은 대용량 데이터 분석 시간을 획기적으로 단축시킨다.12

4. 데이터베이스 환경 내 TiDB의 위치: 비교 분석

TiDB는 기존 데이터베이스 기술들의 장점을 흡수하고 단점을 보완하려는 시도에서 탄생했기 때문에, 그 기술적 위치를 이해하기 위해서는 주요 데이터베이스들과의 비교 분석이 필수적이다.

4.1 TiDB 대 MySQL

TiDB는 MySQL 프로토콜 호환성을 가장 큰 특징 중 하나로 내세우지만, 내부 아키텍처와 핵심 기능 면에서는 근본적인 차이를 보인다.

• 아키텍처: 가장 큰 차이점은 아키텍처이다. MySQL은 단일 서버에서 SQL 처리와 스토리지를 모두 담당하는 모놀리식(monolithic) 구조인 반면, TiDB는 컴퓨팅 계층과 스토리지 계층이 분리된 분산 아키텍처를 채택했다.13 이 구조적 차이가 확장성, 가용성 등 여러 측면에서 다른 특성을 낳는다.
• 확장성: 확장성은 두 데이터베이스를 구분하는 가장 중요한 기준이다. MySQL은 기본적으로 수직적 확장(scale-up)에 의존한다. 읽기 부하 분산을 위해 읽기 복제본(read replica)을 사용하는 수평적 확장이 가능하지만, 쓰기 작업은 여전히 단일 마스터 노드에 집중되어 쓰기 확장성에 한계가 있다. 대규모 확장을 위해서는 Vitess와 같은 외부 미들웨어를 사용하거나 애플리케이션 레벨에서 데이터를 수동으로 분할(sharding)해야 하는데, 이는 아키텍처의 복잡성을 크게 증가시키고 트랜잭션 처리, 스키마 변경 등에서 많은 제약을 초래한다.2 반면, TiDB는 설계 초기부터 수평적 확장(scale-out)을 염두에 두고 만들어졌다. 데이터를 Region 단위로 자동 분할하고 클러스터 전체에 균등하게 분산시키므로, 단순히 노드를 추가하는 것만으로 쓰기와 읽기 성능, 그리고 저장 용량을 선형적으로 확장할 수 있다.2
• 고가용성: MySQL의 고가용성은 주로 마스터-슬레이브 복제(master-slave replication)나 InnoDB Cluster, Percona XtraDB Cluster와 같은 별도의 클러스터링 솔루션을 통해 구성된다. 장애 발생 시 복구 과정이 자동화되어 있지 않거나, 특정 솔루션에 따라 복잡한 설정이 필요할 수 있다. TiDB는 아키텍처 자체에 Raft 합의 알고리즘 기반의 자동 장애 복구(automatic failover) 기능이 내장되어 있다. 스토리지 노드(TiKV)나 관리 노드(PD)에 장애가 발생하면 시스템이 자동으로 이를 감지하고 서비스를 중단 없이 이어가도록 설계되어 있다.54
• 성능: 성능 특성은 워크로드에 따라 상이하다. 단일 서버 환경에서 소량의 데이터를 대상으로 하는 단순한 OLTP 쿼리(예: Primary Key 기반 조회)의 경우, 분산 시스템의 오버헤드가 없는 MySQL이 더 빠른 응답 시간을 보일 수 있다.55 그러나 데이터 양이 수 테라바이트에 달하고, 인덱스를 효과적으로 사용하기 어려운 복잡한 분석(OLAP) 쿼리의 경우, 여러 노드의 CPU 코어를 활용하여 병렬 처리가 가능한 TiDB가 훨씬 뛰어난 성능을 발휘한다.55

4.2 TiDB 대 CockroachDB

TiDB와 CockroachDB는 NewSQL 데이터베이스 시장을 이끄는 대표적인 두 주자이지만, 아키텍처 철학과 목표 시장에서 미묘한 차이를 보인다. 이 둘의 아키텍처 차이는 ’유연성’과 ‘단순성’ 사이의 근본적인 철학적 차이를 드러낸다. TiDB의 모듈형 아키텍처는 각 컴포넌트를 독립적으로 최적화하고 확장할 수 있는 ’유연성’을 제공한다.56 예를 들어, 스토리지 성능이 중요하다면 C++로 작성된 RocksDB 위에 Rust로 TiKV를 구현하여 GC 오버헤드를 제거하고 58, 컴퓨팅 계층은 개발 생산성이 높은 Go로 작성하는 식이다. 이는 각 영역에 최적의 기술을 적용하는 방식이지만, 운영자는 여러 컴포넌트의 상호작용을 이해해야 하는 복잡성이 따른다. 반면, CockroachDB의 통합 아키텍처는 모든 노드가 동일한 역할을 수행하는 ’단순성’을 지향한다.57 “그냥 노드를 추가하면 된다“는 직관적인 확장 모델을 제공하며 운영이 상대적으로 쉽다. 하지만 이는 모든 노드가 SQL 처리와 스토리지 역할을 겸해야 하므로, 특정 워크로드에 대한 최적화가 TiDB만큼 세분화되기 어렵다.

• 호환성 및 생태계: 가장 명확한 차이점은 호환성이다. TiDB는 MySQL 프로토콜과 호환되어 MySQL 생태계를 공략하는 반면, CockroachDB는 PostgreSQL 프로토콜과 호환되어 PostgreSQL 생태계를 목표로 한다.56 이 선택은 각 데이터베이스가 어떤 기존 RDBMS 사용자층을 주된 마이그레이션 대상으로 삼고 있는지를 명확히 보여준다. 이는 두 데이터베이스가 직접적으로 모든 시장에서 경쟁하기보다는, 각각 거대한 기존 RDBMS 시장의 ’분산 버전’으로서 각자의 영역을 구축하고 있는 상호 보완적 경쟁 관계에 있음을 시사한다.
• 아키텍처: TiDB는 컴퓨팅(TiDB Server, Go 언어)과 스토리지(TiKV, Rust 언어)가 명확히 분리된 모듈형 아키텍처를 가진다.56 이 구조는 컴퓨팅과 스토리지 자원을 독립적으로 확장할 수 있는 유연성을 제공한다. CockroachDB는 SQL 계층과 스토리지 계층이 하나의 바이너리에 통합된 P2P(Peer-to-Peer) 방식의 아키텍처를 채택하고 있으며, 주로 Go 언어로 개발되었다.57
• 트랜잭션 모델: 두 데이터베이스 모두 강력한 일관성을 보장하는 분산 트랜잭션을 지원하지만, 그 구현 방식에 차이가 있다. TiDB는 중앙화된 타임스탬프 발급기(PD의 TSO)를 사용하는 Google의 Percolator 모델을 기반으로 한다.56 반면, CockroachDB는 각 노드가 NTP(Network Time Protocol)를 통해 시간을 동기화하고, 이를 기반으로 HLC(Hybrid Logical Clocks) 알고리즘을 사용하여 트랜잭션 순서를 결정한다.56
• 워크로드 지원: TiDB는 컬럼 기반 스토리지 엔진인 TiFlash를 통해 OLTP와 OLAP 워크로드를 동시에 처리하는 HTAP 기능을 네이티브로 강력하게 지원한다.56 CockroachDB 역시 분석 쿼리 성능을 개선하기 위한 기능들을 지속적으로 추가하고 있지만, 전통적으로는 OLTP 워크로드에 더 강점을 보여왔다.

4.3 TiDB 대 NoSQL (MongoDB, DynamoDB 등)

TiDB는 NoSQL의 확장성을 관계형 모델에 접목시킨 NewSQL 데이터베이스로서, 순수 NoSQL 데이터베이스와는 여러 면에서 뚜렷한 차이를 보인다.

• 데이터 모델 및 스키마: TiDB는 행과 열로 구성된 테이블 구조와 사전에 정의된 스키마를 사용하는 관계형 데이터 모델을 따른다. 이는 데이터의 구조적 일관성을 강제한다. 반면, MongoDB(문서), DynamoDB(Key-Value)와 같은 NoSQL 데이터베이스는 스키마가 없거나 유연한(schema-less, flexible schema) 비관계형 데이터 모델을 사용하여 비정형 데이터를 쉽게 저장할 수 있다.5
• 일관성 보장: TiDB의 핵심 가치 중 하나는 분산 환경에서도 강력한 일관성(Strong Consistency)과 ACID 트랜잭션을 보장하는 것이다.35 이는 데이터 정합성이 최우선인 애플리케이션에 적합하다. 반면, 많은 NoSQL 데이터베이스는 CAP 이론에 따라 일관성을 다소 완화하고 가용성(Availability)과 분할 내성(Partition Tolerance)을 우선시하는 결과적 일관성(Eventual Consistency) 모델(BASE 철학)을 채택한다.5
• 쿼리 언어: TiDB는 표준 SQL을 지원하여 복잡한 조인(JOIN), 서브쿼리, 집계 함수 등 강력하고 표현력 높은 데이터 조작이 가능하다.60 NoSQL 데이터베이스는 각자의 데이터 모델에 특화된 API나 제한적인 쿼리 언어를 제공하는 경우가 많아, 복잡한 데이터 관계를 표현하고 조회하는 데 한계가 있을 수 있다.60

5. TiDB 생태계와 운영 관리

TiDB는 강력한 데이터베이스 코어뿐만 아니라, 클러스터의 배포, 운영, 데이터 이동 등을 지원하는 풍부한 도구 생태계를 갖추고 있다. 이러한 생태계는 TiDB를 실제 프로덕션 환경에서 효과적으로 사용하기 위한 필수 요소이다.

5.1 배포 옵션

TiDB는 기업의 인프라 환경과 운영 전략에 따라 다양한 배포 옵션을 제공한다. 이는 기업이 인프라에 대한 통제 수준과 운영 부담 사이에서 비즈니스 요구에 가장 적합한 균형점을 선택할 수 있게 해준다.

• 온프레미스 / 자체 관리형 클라우드: 기업이 소유한 물리 서버나 프라이빗/퍼블릭 클라우드의 가상 머신에 직접 TiDB 클러스터를 배포하는 방식이다.63 이 경우, TiUP이라는 커맨드라인 도구를 사용하여 클러스터의 설치, 설정, 확장, 업그레이드 등 전체 생명주기를 관리한다.64 이 방식은 하드웨어부터 운영체제, 네트워크까지 모든 환경을 직접 제어할 수 있어 규제가 엄격하거나 고도로 맞춤화된 환경을 요구하는 기업에 적합하지만, 높은 수준의 운영 전문성이 필요하다.
• Kubernetes: TiDB는 클라우드 네이티브 환경의 표준으로 자리 잡은 Kubernetes에 배포하고 운영하는 것을 공식적으로 지원한다. TiDB Operator는 Kubernetes의 Operator 패턴을 활용하여 TiDB 클러스터의 배포, 스케일링, 장애 복구, 백업, 업그레이드와 같은 복잡한 운영 작업을 자동화하는 컨트롤러이다.6 Kubernetes의 선언적 API를 통해 원하는 클러스터 상태를 정의하면, TiDB Operator가 현재 상태를 지속적으로 모니터링하고 원하는 상태에 도달하도록 조정한다. 이는 인프라에 대한 통제권을 유지하면서도 데이터베이스 운영 부담을 크게 줄일 수 있어 현대적인 DevOps 환경에 이상적이다.67
• 완전 관리형 클라우드 (TiDB Cloud): PingCAP이 직접 제공하는 DBaaS(Database as a Service) 형태의 서비스이다.68 사용자는 AWS나 GCP와 같은 퍼블릭 클라우드 위에서 몇 번의 클릭만으로 TiDB 클러스터를 생성하고 사용할 수 있다. 모든 인프라 관리, 패치, 백업, 모니터링 등의 운영 업무는 PingCAP이 책임지므로, 사용자는 애플리케이션 개발에만 집중할 수 있다.69 TiDB Cloud는 워크로드에 따라 자원이 자동으로 확장/축소되는 서버리스(Serverless) 옵션과, 예측 가능한 성능을 위해 고정된 자원을 할당하는 전용(Dedicated) 옵션을 제공하여 다양한 규모와 요구사항에 대응한다.70

5.2 핵심 관리 도구

TiDB의 도구 생태계는 개별 유틸리티의 집합이 아니라, 데이터의 전체 생명주기, 즉 ’데이터의 흐름’을 중심으로 유기적으로 설계되어 있다. 이는 TiDB가 단순히 데이터를 저장하는 종착지가 아니라, 다양한 데이터 소스를 통합하고, 실시간으로 처리하며, 그 결과를 다시 다른 시스템으로 전파하는 중앙 데이터 허브로서 기능하도록 지원한다.

• TiUP: TiDB의 공식 패키지 매니저이자 클러스터 관리 도구이다.64

tiup cluster deploy, start, scale-out, upgrade 와 같은 직관적인 명령어를 통해 복잡한 분산 클러스터의 배포, 운영, 확장, 업그레이드 작업을 극적으로 간소화한다.72 TiDB뿐만 아니라 PD, TiKV, TiFlash, 모니터링 컴포넌트 등 TiDB 생태계의 모든 구성요소를 통합 관리한다.74

• 데이터 마이그레이션 도구:

• TiDB Data Migration (DM): 기존 MySQL 또는 MariaDB에서 TiDB로 데이터를 마이그레이션하기 위한 통합 솔루션이다.75 초기 데이터 전체를 이전하는 풀 마이그레이션(full migration)과 이후의 변경 사항을 지속적으로 동기화하는 증분 복제(incremental replication)를 모두 지원한다. 여러 개의 MySQL 샤드(shard)를 하나의 TiDB 클러스터로 병합하는 기능도 제공하여, 샤딩된 MySQL 환경에서 마이그레이션하는 시나리오에 특히 유용하다.16

• TiDB Lightning & Dumpling: 대용량 데이터의 초기 적재를 고속으로 수행하기 위한 도구 조합이다. Dumpling은 MySQL 또는 TiDB에서 데이터를 병렬로 익스포트하여 SQL 파일이나 CSV 파일로 생성하는 역할을 한다.64 TiDB Lightning은 Dumpling으로 생성된 파일을 읽어 TiDB 클러스터에 직접 Key-Value 형태로 변환하여 매우 빠른 속도로 임포트한다.64 수 테라바이트급의 대용량 데이터를 마이그레이션할 때 주로 사용된다.

• 백업 및 복구 (Backup & Restore - BR): 대규모 TiDB 클러스터의 데이터를 물리적으로 백업하고 복원하기 위한 커맨드라인 도구이다.75 분산 아키텍처의 이점을 활용하여 여러 TiKV 노드에서 동시에 백업/복원 작업을 수행하므로, 대용량 데이터도 빠르고 효율적으로 처리할 수 있다.64

• 데이터 스트리밍 (TiCDC - Change Data Capture): TiDB 클러스터에서 발생하는 데이터 변경 사항(INSERT, UPDATE, DELETE)을 실시간으로 캡처하여 다른 시스템으로 스트리밍하는 도구이다.77 변경 로그를 Kafka와 같은 메시지 큐나 다른 데이터베이스(MySQL, TiDB 등)로 전송하여, 마이크로서비스 아키텍처에서의 이벤트 전파, 데이터 동기화, 실시간 데이터 웨어하우징 등 다양한 시나리오에 활용될 수 있다.18

• 분석 엔진 연동 (TiSpark): TiDB를 Apache Spark 생태계와 연결하는 커넥터이다.79 TiSpark를 사용하면 Spark SQL 쿼리를 통해 TiKV에 저장된 데이터를 직접, 그리고 병렬로 읽고 분석할 수 있다. 이는 TiDB의 SQL 계층을 거치지 않고 스토리지 계층에 직접 접근하므로, 복잡하고 무거운 OLAP 쿼리나 머신러닝 워크로드를 수행하는 데 최적화되어 있다.4

6. 산업별 적용 사례 및 성능 분석

TiDB의 아키텍처적 강점은 다양한 산업 분야에서 발생하는 실제적인 데이터 문제를 해결하며 그 가치를 입증하고 있다. 여러 산업의 성공 사례들은 공통적으로 ’성장통’이라는 문제를 TiDB로 해결했음을 보여준다. 금융, 이커머스, 게이밍 등 전혀 다른 산업 분야이지만, 이들이 TiDB를 도입하게 된 근본적인 이유는 동일하다: 비즈니스가 성공적으로 성장함에 따라 기존 데이터베이스(주로 MySQL)가 더 이상 데이터 양과 트래픽을 감당할 수 없게 된 것이다. 기존 RDBMS의 수직적 확장과 수동 샤딩은 임시방편일 뿐, 근본적인 해결책이 되지 못했다.2 TiDB는 이 지점에서 ’수평적 확장성’이라는 명확한 해결책을 제공하며, 이는 TiDB가 특정 산업에 국한된 솔루션이 아니라 ’빠르게 성장하는 디지털 비즈니스’라는 공통 분모를 가진 모든 기업에게 매력적인 대안이 될 수 있음을 시사한다.

6.1 금융 서비스 (Financial Services)

금융 산업은 데이터의 정확성, 일관성, 가용성에 대해 타협이 불가능한, 가장 엄격한 요구사항을 가진 분야 중 하나이다.6 TiDB는 강력한 일관성을 보장하는 분산 ACID 트랜잭션과 내장된 고가용성 기능을 통해 이러한 요구사항을 충족시킨다.7

• 결제 시스템 현대화: 대규모 결제 트랜잭션을 처리하는 시스템은 기존 RDBMS의 확장성 한계에 가장 먼저 부딪히는 영역이다. 여러 금융 기관들은 TiDB를 도입하여 초당 수만 건의 트랜잭션을 안정적으로 처리하고 있다. 특히 여러 데이터센터에 클러스터를 분산 배포하는 방식을 통해, 하나의 데이터센터 전체에 장애가 발생하더라도 30초 이내의 복구 시간 목표(RTO)와 데이터 유실 제로(RPO=0)를 달성하는 재해 복구 시스템을 구축했다.6
• 실시간 사기 탐지(Fraud Detection): 전통적인 사기 탐지 시스템은 ETL을 통해 데이터를 분석 시스템으로 옮긴 후 배치(batch) 작업으로 이상 거래를 분석했기 때문에, 사기 발생과 탐지 사이에 시간적 간극이 존재했다. TiDB의 HTAP 아키텍처는 이러한 문제를 해결한다. TiKV에서 발생하는 실시간 거래 데이터를 TiFlash에서 지연 없이 분석하여, 비정상적인 패턴을 즉시 탐지하고 조치할 수 있게 한다.19 이는 금융 손실을 최소화하고 고객 자산을 보호하는 데 결정적인 역할을 한다.
• 사례 연구:
• 글로벌 Top 150 은행: 한 글로벌 은행은 기존 빅데이터 기술 스택(Hive, Elasticsearch, HBase)으로 구축했던 역사적 은행 거래 내역 조회 시스템의 성능 병목 문제를 해결하기 위해 TiDB를 도입했다. TiDB의 분산 아키텍처는 계좌번호, 거래일, 금액 등 복잡한 다중 조건 검색 쿼리를 효율적으로 처리했으며, 도시 내 두 개의 데이터센터에 걸친 액티브-액티브(active-active) 배포를 통해 99.99%의 고가용성을 확보했다. 또한, 표준 SQL을 사용하게 되면서 여러 이기종 데이터 플랫폼을 관리해야 했던 복잡성을 제거하고 애플리케이션 개발 비용을 절감했다.83
• Plaid: 북미 최대의 금융 데이터 플랫폼인 Plaid는 기존에 사용하던 Amazon Aurora MySQL의 확장성과 유지보수 문제에 직면했다. 이들은 TiDB로의 마이그레이션을 통해 유지보수 노력을 96% 줄이고, 서비스 중단 없는 온라인 스키마 변경 및 업그레이드를 실현했다. 이 과정에서 TiDB의 분산 환경 특성(예: Foreign Key 제약, Auto-increment ID 동작 방식)에 맞춰 애플리케이션 로직을 일부 수정하는 과정을 거쳤다.84

6.2 전자상거래 (E-commerce)

전자상거래 플랫폼은 블랙 프라이데이나 사이버 먼데이와 같은 대규모 할인 행사 기간 동안 평소의 수십, 수백 배에 달하는 트래픽 급증을 감당해야 한다. TiDB의 탄력적인 수평 확장성은 이러한 예측 불가능한 피크 타임에 대응하는 데 최적화되어 있다.20

• 주문 및 재고 관리: 사용자의 주문이 접수되면 결제, 재고 차감, 배송 요청 등 여러 마이크로서비스에 걸쳐 데이터의 일관성이 유지되어야 한다. TiDB의 분산 트랜잭션 기능은 이러한 복잡한 워크플로우 전반에 걸쳐 데이터 정합성을 보장하여, 재고 불일치나 중복 주문과 같은 문제를 방지한다.86
• 실시간 개인화 추천 및 분석: TiDB의 HTAP 기능은 이커머스 분야에서 강력한 비즈니스 가치를 창출한다. 전통적으로 기업들은 OLTP 시스템의 데이터를 밤새 ETL 작업을 통해 데이터 웨어하우스(DW)로 옮긴 후 다음 날 분석했다(T+1). 하지만 TiDB를 사용하면 고객이 방금 장바구니에 담거나 조회한 상품 정보를 ‘즉시’ 분석하여 관련 상품을 추천하거나, 실시간 재고 상황에 따른 동적 가격 책정 전략을 구사할 수 있다.86 이는 분석과 실행 사이의 시간적 간극을 제거하여, 기업이 과거 데이터 기반의 ’사후 대응’에서 현재 데이터 기반의 ’즉시 행동’으로 비즈니스 운영 방식을 근본적으로 바꾸게 한다.
• 사례 연구:
• Flipkart: 인도의 거대 전자상거래 기업 Flipkart는 비즈니스 성장에 따라 MySQL의 확장성 한계에 도달했다. 이들은 TiDB를 도입하여 초당 백만 건 이상의 쿼리를 처리하는 대규모 시스템을 구축했으며, 무중단 유지보수를 통해 24/7 서비스 가용성을 확보했다. TiDB의 확장성은 Flipkart가 비즈니스 혁신에 더 빠르게 집중할 수 있는 기반이 되었다.88
• SHOPLINE: 글로벌 이커머스 솔루션 제공업체인 SHOPLINE은 기존 TiDB 4.0 버전에서 6.5 버전으로 업그레이드하면서 아키텍처를 최적화했다. 이를 통해 전체 클러스터 머신 수를 50% 줄이고, 가용 영역 간 네트워크 트래픽을 30% 감소시키는 등 상당한 비용 절감 효과를 거두었다. 동시에 시스템 안정성과 성능을 향상시켜 비즈니스 성장을 뒷받침했다.84

6.3 온라인 게이밍 (Online Gaming)

온라인 게임은 수백만 명의 동시 접속자가 발생시키는 대규모의 실시간 상호작용을 처리해야 하므로, 데이터베이스에 극도로 낮은 지연 시간(low latency)과 높은 처리량(high throughput)을 요구한다.90

• 게임 상태 및 사용자 데이터 관리: 플레이어의 상태, 아이템, 재화, 결제 내역 등 방대하고 지속적으로 변경되는 데이터를 안정적으로 관리해야 한다. TiDB는 수동 샤딩의 복잡성 없이 노드 추가만으로 용량과 성능을 확장할 수 있어, 게임의 성공에 따른 사용자 및 데이터 증가에 유연하게 대응할 수 있다.3
• 실시간 분석 및 운영: 게임 내에서 발생하는 로그 데이터를 실시간으로 분석하여 어뷰징 유저를 탐지하거나, 사용자 프로파일링을 통해 정교한 매치메이킹 시스템을 구현하고, 게임 밸런스를 조절하는 등 데이터 기반의 게임 운영에 활용된다.90
• 사례 연구:
• NetEase Games: 중국의 대표적인 게임 개발사인 NetEase Games는 급증하는 데이터로 인해 단일 MySQL 인스턴스의 성능 한계에 부딪혔다. 이들은 MySQL 미들웨어, CockroachDB 등 다양한 솔루션을 검토 및 테스트한 후, MySQL 호환성과 수평 확장성, 그리고 HTAP 지원 능력에서 강점을 보인 TiDB를 최종 선택했다. TiDB를 통해 여러 게임의 데이터를 하나의 거대한 데이터 풀로 통합하고, 이를 기반으로 리포팅, 모니터링, 빅데이터 분석 등 다양한 데이터 플랫폼 서비스를 구축했다.3
• Capcom: 일본의 유명 게임 회사인 Capcom은 새로운 온라인 게임의 백엔드 데이터베이스로 완전 관리형 서비스인 TiDB Cloud를 채택했다. 이를 통해 데이터베이스 인프라 운영 및 관리에 대한 부담을 크게 줄이고, 게임 개발에 핵심 역량을 집중할 수 있었다. 또한, 게임 출시 후 예상치 못한 사용자 급증에도 클릭 몇 번으로 클러스터를 유연하게 확장할 수 있는 TiDB Cloud의 탄력성은 변동성이 큰 게임 산업에 매우 적합했다.92

6.4 SaaS 플랫폼 및 기타

SaaS(Software as a Service) 플랫폼은 다수의 고객(tenant)이 하나의 시스템을 공유하는 멀티테넌시 환경과, 예측 불가능한 고객 성장에 유연하게 대응할 수 있는 확장성을 요구한다.90

• 사례 연구:
• Bolt: 미국의 결제 서비스 기업 Bolt는 수천 개의 마이크로서비스 아키텍처를 지원하기 위해 기존 MySQL 인프라를 TiDB로 현대화했다. TiDB의 수평 확장성과 강력한 일관성은 마이크로서비스 간의 데이터 정합성을 유지하면서 대규모 트래픽을 처리하는 데 핵심적인 역할을 했다. 또한 AWS의 다양한 인스턴스 타입을 유연하게 활용하여 비용 효율적인 아키텍처를 구축할 수 있었다.36
• Pinterest: 이미지 공유 소셜 미디어 서비스인 Pinterest는 TiDB를 도입하여 인프라 비용을 80% 이상 절감하는 성과를 거두었다. 이는 대규모 데이터 처리에 대한 TiDB의 효율성을 보여주는 대표적인 사례이다.84
• Dailymotion: 프랑스의 비디오 공유 플랫폼 Dailymotion은 TiDB를 사용하여 실시간 트랜잭션 처리에서 발생하던 확장성 병목 현상을 해결하고, 안정적인 서비스를 제공할 수 있게 되었다.84

7. 결론: TiDB의 현재와 미래 전망

TiDB는 지난 몇 년간 분산 데이터베이스 시장에서 가장 주목받는 기술 중 하나로 자리매김했다. 그 성공의 이면에는 현대 디지털 비즈니스가 직면한 근본적인 데이터 문제, 즉 확장성, 일관성, 그리고 실시간 분석 요구를 하나의 통합된 아키텍처 안에서 해결하려는 명확한 비전이 있다.

7.1 TiDB의 기술적 강점과 한계 요약

• 강점: TiDB의 핵심 경쟁력은 네 가지로 요약할 수 있다. 첫째, 수평적 확장성은 노드 추가만으로 성능과 용량을 선형적으로 확장할 수 있게 하여 비즈니스 성장에 따른 데이터 인프라의 한계를 제거한다. 둘째, Raft와 Percolator 모델에 기반한 강력한 일관성과 고가용성은 금융 서비스와 같이 데이터 정합성이 최우선인 미션 크리티컬 애플리케이션에 대한 신뢰를 제공한다. 셋째, MySQL 호환성은 기존 애플리케이션의 마이그레이션 장벽을 낮추고 방대한 MySQL 생태계를 활용할 수 있게 하는 실용적인 장점이다. 마지막으로, TiKV와 TiFlash를 결합한 단일 시스템 내 HTAP 통합은 복잡한 ETL 파이프라인 없이 실시간 데이터 분석을 가능하게 하여 데이터 기반 의사결정의 속도를 혁신한다.17

• 한계 및 고려사항: TiDB가 모든 문제에 대한 만병통치약은 아니다. 도입을 고려할 때 몇 가지 한계와 기술적 특성을 신중하게 검토해야 한다.

• MySQL과의 불완전한 호환성: TiDB는 MySQL 프로토콜과 구문에 대해 높은 호환성을 제공하지만 100% 동일하지는 않다. 저장 프로시저(Stored Procedure), 트리거(Trigger), 사용자 정의 함수(UDF)와 같은 일부 고급 기능은 지원하지 않거나 제한적으로 지원된다.14 또한, 분산 환경의 특성상

AUTO_INCREMENT의 동작 방식이 MySQL과 달라 순차적인 ID 생성을 보장하지 않으므로, 이에 의존하는 애플리케이션 로직은 수정이 필요할 수 있다.85

• 분산 시스템의 내재적 복잡성: TiDB는 내부적으로 매우 정교하고 복잡한 분산 시스템이다. 이는 단일 노드 RDBMS에 비해 최소 요구 하드웨어 사양이 높고, 아키텍처를 이해하고 최적화하는 데 더 많은 학습이 필요함을 의미한다. 또한, 노드 간 통신이 필수적이므로 네트워크 지연 시간과 안정성이 전체 성능에 큰 영향을 미칠 수 있다.41

• 성능 특성: 특정 워크로드에서는 성능적 한계가 보고되기도 했다. 예를 들어, 극심한 쓰기 경합이 발생하는 시나리오나 특정 쿼리 패턴에서 쓰기 성능과 확장성의 한계로 인해 애플리케이션 코드 레벨에서 비효율적인 우회 구현이 필요했던 사례가 존재한다.95 따라서 도입 전, 실제 워크로드를 사용한 철저한 성능 검증(PoC)이 필수적이다.

7.2 미래 전망: 클라우드 네이티브와 AI 통합

TiDB의 장기적인 비전은 ’데이터베이스의 재통합(The Great Re-unification)’으로 요약할 수 있다. 지난 수십 년간 데이터베이스 시장은 트랜잭션용 RDBMS, 분석용 데이터 웨어하우스, 검색용 검색 엔진, 스트리밍용 처리 플랫폼 등으로 고도로 전문화되고 파편화되는 길을 걸어왔다. TiDB는 HTAP를 통해 OLTP와 OLAP의 통합을 시작으로 52, TiSpark를 통해 빅데이터 분석 생태계와 연결하고 79, 최근에는 벡터 검색 기능을 추가하며 AI/검색 워크로드까지 포괄하려 하고 있다.96 이러한 움직임은 파편화된 데이터 시스템들을 다시 하나의 통합된 플랫폼으로 모으려는 명확한 방향성을 보여준다. 이는 데이터 아키텍처의 복잡성을 근본적으로 줄이고, “하나의 게이트웨이로 모든 데이터에 접근한다“는 야심 찬 목표를 향한 여정이다.52

• 클라우드 네이티브 심화: TiDB는 이미 TiDB Operator와 TiDB Cloud를 통해 Kubernetes 및 클라우드 환경과의 깊은 통합을 이루었다.6 최근 발표된 TiFlash의 스토리지/컴퓨팅 분리 및 Amazon S3 지원 아키텍처는 29 클라우드 환경에서의 비용 효율성과 탄력성을 극대화하려는 전략적 방향을 명확히 보여준다. 앞으로 이러한 클라우드 네이티브 특성은 더욱 강화될 것으로 예상된다.
• AI 및 데이터 허브로서의 역할: 실시간 스트림 처리(stream computing)와 데이터 허브(data hub)로서의 활용 사례가 꾸준히 증가하고 있다.18 특히 최근에는 생성형 AI(GenAI) 애플리케이션을 위한 통합 스토리지로서의 역할을 강조하며, 벡터 검색(Vector Search)과 같은 기능을 핵심 로드맵에 포함시키고 있다.94 이는 TiDB가 단순히 데이터를 저장하고 조회하는 전통적인 데이터베이스의 역할을 넘어, 차세대 AI/ML 워크로드를 위한 핵심 데이터 플랫폼으로 진화하고 있음을 시사한다.

7.3 TiDB 도입을 위한 아키텍처 고려사항

TiDB의 성공적인 도입을 위해서는 기술적 특성을 명확히 이해하고, 비즈니스 요구사항에 맞춰 신중한 아키텍처적 결정을 내려야 한다.

• 적합한 시나리오 선택: TiDB는 대규모 데이터(수 테라바이트 이상), 높은 동시성, 예측 불가능한 성장에 따른 수평적 확장성 요구, 그리고 실시간 분석(HTAP) 필요성이 명확한 시나리오에서 가장 큰 가치를 발휘한다. 소규모의 정적인 워크로드에는 오히려 기존의 단일 노드 RDBMS가 더 비용 효율적이고 간단한 해결책일 수 있다.
• 철저한 사전 검증: 마이그레이션을 고려한다면, 사전에 호환성 검증 도구를 사용하여 기존 애플리케이션과의 호환성 문제를 파악하고 16, 실제 워크로드와 유사한 환경에서 성능 벤치마크를 철저히 수행해야 한다. 또한, 분산 환경의 특성을 고려하여 핫스팟을 유발할 수 있는 스키마 설계를 피하고, 트랜잭션 크기를 적절히 조절하는 등의 최적화 전략을 수립해야 한다.
• 운영 모델 결정: 조직의 기술 역량, 보안 정책, 비용 모델을 종합적으로 고려하여 최적의 운영 모델을 선택해야 한다. 높은 수준의 인프라 통제권과 맞춤화가 필요하다면 자체 관리형(Self-Managed)을, 클라우드 네이티브 환경과 운영 자동화를 추구한다면 Kubernetes 기반 배포를, 인프라 운영 부담을 최소화하고 애플리케이션 개발에 집중하고 싶다면 완전 관리형 서비스(TiDB Cloud)를 선택하는 것이 합리적이다.

결론적으로, TiDB는 분산 시스템의 내재적 복잡성을 가지고 있지만, 그 복잡성을 TiUP, TiDB Operator, TiDB Cloud와 같은 도구들을 통해 효과적으로 추상화하고 있다. 기술의 깊이만큼이나 그 기술을 사용자에게 얼마나 쉽게 제공하느냐, 즉 ’복잡성 추상화’의 완성도가 TiDB의 대중적 채택과 미래 성공을 결정짓는 핵심적인 과제가 될 것이다. TiDB는 데이터베이스 기술의 새로운 지평을 열었으며, 앞으로도 클라우드와 AI 시대를 이끄는 핵심 데이터 플랫폼으로서 그 역할을 계속해서 확장해 나갈 것으로 전망된다.

8. 참고 자료

1. TiDB vs Traditional Databases: Unleashing HTAP Power, https://www.pingcap.com/article/tidb-vs-traditional-databases-unleashing-htap-power/
2. TiDB vs Traditional MySQL Clusters: When to Migrate and Why? | by Raj Suvariya | Medium, https://medium.com/@rajsuvariya/tidb-vs-traditional-mysql-clusters-when-to-migrate-and-why-0b7d18dad2fd
3. Why NetEase Games Chose TiDB over Other Storage Solutions, https://www.pingcap.com/case-study/why-we-chose-tidb-over-other-mysql-based-and-newsql-storage-solutions/
4. A Raft-based HTAP Database - TiDB - VLDB Endowment, https://www.vldb.org/pvldb/vol13/p3072-huang.pdf
5. Exploring Open-Source NoSQL Databases and TiDB’s Hybrid Model, https://www.pingcap.com/article/exploring-open-source-nosql-databases-and-tidbs-hybrid-model/
6. TiDB 소개 - devkuma, https://www.devkuma.com/docs/tidb/overview/
7. Embracing NewSQL: Why We Chose TiDB over MongoDB and MySQL, https://www.pingcap.com/case-study/embracing-newsql-why-we-chose-tidb-over-mongodb-and-mysql/
8. TIDB - 나그네소 - 티스토리, https://sonhyunwoong.tistory.com/9
9. Understanding OLAP vs OLTP in TiDB’s HTAP Model, https://www.pingcap.com/article/understanding-olap-vs-oltp-in-tidbs-htap-model/
10. Our Mission is to empower engineers and enable business value with speed, scale and agility. - PingCAP, https://www.pingcap.com/about-us/
11. en.wikipedia.org, https://en.wikipedia.org/wiki/TiDB
12. Exploring NewSQL: Scalability Meets Consistency in 2024 | TiDB, https://www.pingcap.com/article/exploring-newsql-scalability-meets-consistency-in-2024/
13. TiDB vs. MySQL: a Complete Comparison in 2025 - Bytebase, https://www.bytebase.com/blog/tidb-vs-mysql/
14. TiDB Architecture FAQs, https://docs.pingcap.com/tidb/stable/tidb-faq/
15. Third-Party Tools Supported by TiDB | TiDB Docs, https://docs.pingcap.com/tidb/stable/dev-guide-third-party-support/
16. Verification of scalability and compatibility of TiDB for DBMS migration, http://journal.dcs.or.kr/xml/34813/34813.pdf
17. What is TiDB Self-Managed, https://docs.pingcap.com/tidb/stable/overview
18. Building Scalable Real-Time Analytics Pipelines with TiDB | by firman brilian - Medium, https://medium.com/@firmanbrilian/building-scalable-real-time-analytics-pipelines-with-tidb-1e250d30468a
19. TiDB: Scalable HTAP Database for Real-Time Analytics, https://www.pingcap.com/article/tidb-scalable-htap-database-for-real-time-analytics/
20. Mastering TiDB: Scalability and Architecture Explained, https://www.pingcap.com/article/mastering-tidb-scalability-and-architecture-explained/
21. TiDB Architecture | TiDB Docs, https://docs.pingcap.com/tidb/stable/tidb-architecture
22. Understanding TiDB’s Cluster Architecture and Core Components, https://www.pingcap.com/article/understanding-tidbs-cluster-architecture-and-core-components/
23. TiDB Computing | TiDB Docs - PingCAP, https://docs.pingcap.com/tidb/stable/tidb-computing
24. Concepts - TiKV, https://tikv.org/docs/3.0/concepts/overview/
25. Architecture - TiKV, https://tikv.org/docs/3.0/concepts/architecture/
26. FAQs - TiKV, https://tikv.org/docs/5.1/reference/faq/
27. TiFlash Overview | TiDB Docs, https://docs.pingcap.com/tidbcloud/tiflash-overview
28. TiFlash Overview | TiDB Docs - PingCAP, https://docs.pingcap.com/tidb/stable/tiflash-overview
29. TiFlash Disaggregated Storage and Compute Architecture and S3 Support | TiDB Docs, https://docs.pingcap.com/tidb/stable/tiflash-disaggregated-and-s3/
30. Home · tikv/pd Wiki - GitHub, https://github.com/tikv/pd/wiki
31. TiDB Scheduling | TiDB Docs, https://docs.pingcap.com/tidb/stable/tidb-scheduling
32. TiDB Scheduling: The Secret Weapon for Peak Database Performance - Mydbops, https://www.mydbops.com/blog/tidb-scheduling-for-peak-database-performance
33. TiDB Data Migration (DM) Best Practices, https://docs.pingcap.com/tidb/stable/dm-best-practices
34. TiDB: A Raft-based HTAP Database - Murat Demirbas, http://muratbuffalo.blogspot.com/2023/10/tidb-raft-based-htap-database.html
35. Exploring TiDB’s Distributed SQL Database Architecture, https://www.pingcap.com/article/exploring-tidbs-distributed-sql-database-architecture/
36. Modernizing MySQL: Bolt Scales 1000s of Microservices with TiDB, https://www.pingcap.com/case-study/bolt-modernizing-mysql-tidb-scale-thousands-microservices-aws/
37. Mastering Horizontal Scaling in Distributed SQL Databases - TiDB, https://www.pingcap.com/article/mastering-horizontal-scaling-in-distributed-sql-databases/
38. TiDB’s Horizontal Scaling: A Distributed Architecture Guide, https://www.pingcap.com/article/tidbs-horizontal-scaling-a-distributed-architecture-guide/
39. Manually Scale TiDB on Kubernetes, https://docs.pingcap.com/tidb-in-kubernetes/stable/scale-a-tidb-cluster
40. Raft and High Availability | TiDB, https://www.pingcap.com/blog/raft-and-high-availability/
41. Understanding TiDB’s Raft Consensus for Distributed Databases, https://www.pingcap.com/article/understanding-tidbs-raft-consensus-for-distributed-databases/
42. TiDB’s High Availability & Disaster Recovery Explained, https://www.pingcap.com/article/tidbs-high-availability-disaster-recovery-explained/
43. Mastering TiDB: Scalability, Performance, and High Availability, https://www.pingcap.com/article/mastering-tidb-scalability-performance-and-high-availability/
44. Transforming Financial Apps with Scalable NewSQL Database - TiDB, https://www.pingcap.com/article/transforming-financial-apps-with-scalable-newsql-database/
45. Transaction - TiDB Development Guide, https://pingcap.github.io/tidb-dev-guide/understand-tidb/transaction.html
46. Percolator - TiKV, https://tikv.org/deep-dive/distributed-transaction/percolator/
47. Implementing Distributed Transactions the Google Way: Percolator vs. Spanner - Yugabyte, https://www.yugabyte.com/blog/implementing-distributed-transactions-the-google-way-percolator-vs-spanner/
48. TiDB Best Practices | TiDB Docs, https://docs.pingcap.com/tidb/stable/tidb-best-practices
49. Deep Dive into Distributed Transactions in TiKV and TiDB | by Jinpeng Zhang | Medium, https://dataturbo.medium.com/deep-dive-into-distributed-transactions-in-tikv-and-tidb-80337b4104cb
50. Explore HTAP | TiDB Docs, https://docs.pingcap.com/tidb/stable/explore-htap
51. OLTP vs OLAP : Unveiling Crucial Data Processing Contrasts - Airbyte, https://airbyte.com/data-engineering-resources/olap-vs-oltp
52. The Past, Present, and Future of TiDB as an HTAP Database - Medium, https://pingcap.medium.com/the-past-present-and-future-of-tidb-as-an-htap-database-b9fa96ecd1c7
53. pingcap/tiflash: The analytical engine for TiDB and TiDB Cloud. Try free: https://tidbcloud.com/free-trial - GitHub, https://github.com/pingcap/tiflash
54. What are the main differences between TiDB and MySQL? What are the advantages? - Translated, https://ask.pingcap.com/t/what-are-the-main-differences-between-tidb-and-mysql-what-are-the-advantages/3423
55. A Quick Look into TiDB Performance on a Single Server - Percona, https://www.percona.com/blog/a-quick-look-into-tidb-performance-on-a-single-server/
56. What are the advantage of CockroackDB over TiDB/TiKV? - Quora, https://www.quora.com/What-are-the-advantage-of-CockroackDB-over-TiDB-TiKV
57. TiDB vs. CockroachDB: the Distributed Clash between MySQL and PostgreSQL - Bytebase, https://www.bytebase.com/blog/tidb-vs-cockroachdb/
58. There are some key differences between TiDB and Cockroach. 1. User interface and… | Hacker News, https://news.ycombinator.com/item?id=15500582
59. CockroachDB / TiDB - Reddit, https://www.reddit.com/r/CockroachDB/comments/1814ucl/cockroachdb_tidb/
60. Relational vs. Non-Relational Databases: Settle the Debate - TiDB, https://www.pingcap.com/article/relational-vs-non-relational-databases-whats-the-difference/
61. Explore how TiDB combines traditional RDBMS with NoSQL’s scalability | by TechLatest.Net, https://medium.com/@techlatest.net/explore-how-tidb-combines-traditional-rdbms-with-nosqls-scalability-a63d0e9b9223
62. TiDB vs. Amazon DynamoDB: A Detailed Comparison for Modern Applications, https://www.geeksforgeeks.org/dynamo-db/tidb-vs-amazon-dynamodb-a-detailed-comparison-for-modern-applications/
63. TiDB Self-Managed: Complete Control Over Your Distributed SQL Database, https://www.pingcap.com/tidb-self-managed/
64. TiDB Tools Overview, https://docs.pingcap.com/tidb/stable/ecosystem-tool-user-guide/
65. TiDB operator creates and manages TiDB clusters running in Kubernetes. - GitHub, https://github.com/pingcap/tidb-operator
66. TiDB Operator Architecture | TiDB Docs, https://docs.pingcap.com/tidb-in-kubernetes/stable/architecture
67. Deploy TiDB Operator and a TiDB Cluster on KubeSphere, https://kubesphere.io/docs/v3.4/application-store/external-apps/deploy-tidb/
68. pingcap/tidb - Docker Hub, https://hub.docker.com/r/pingcap/tidb
69. FAQs - TiDB, https://www.pingcap.com/faqs/
70. TiDB Cloud Dedicated: A More Scalable MySQL Alternative, https://www.pingcap.com/tidb-cloud-dedicated/
71. Scalability | TiDB Docs - PingCAP, https://docs.pingcap.com/tidbcloud/scalability-concepts/
72. fewdan/tiup-cluster: Cluster management component of TiUP - GitHub, https://github.com/fewdan/tiup-cluster
73. TiUP Cluster | TiDB Docs - PingCAP, https://docs.pingcap.com/tidb/stable/tiup-component-cluster/
74. TiUP, https://tiup.io/
75. Download TiDB Tools | TiDB Docs, https://docs.pingcap.com/tidb/v5.4/download-ecosystem-tools/
76. TiDB Data Migration Overview | TiDB Docs, https://docs.pingcap.com/tidb/stable/dm-overview
77. TiDB Migration Tools Overview | TiDB Docs, https://docs.pingcap.com/tidb/stable/migration-tools
78. TiDB Tools Use Cases, https://docs.pingcap.com/tidb/stable/ecosystem-tool-user-case/
79. TiDB, Powered by PingCAP, https://www.pingcap.com/
80. Optimizing TiDB for Financial Services: Best Practices & Benefits, https://www.pingcap.com/article/optimizing-tidb-for-financial-services-best-practices-benefits/
81. Achieving Ultra-Low Latency in Financial Transactions with TiDB, https://www.pingcap.com/article/achieving-ultra-low-latency-in-financial-transactions-with-tidb/
82. Transforming Financial Services with Real-Time Data Processing - TiDB, https://www.pingcap.com/article/transforming-financial-services-with-real-time-data-processing/
83. Top 150 Global Bank Enhances Bank Statement Access with TiDB | TiDB, https://www.pingcap.com/case-study/top-150-global-bank-enhances-bank-statement-access-with-tidb/
84. TiDB Customers, https://www.pingcap.com/customers/
85. Cutting over: Our journey from AWS Aurora MySQL to TiDB - Plaid, https://plaid.com/blog/switching-to-tidb/
86. TiDB: Solving E-commerce Challenges with Distributed SQL, https://www.pingcap.com/article/tidb-solving-e-commerce-challenges-with-distributed-sql/
87. Boost E-commerce Efficiency with TiDB: Case Studies & Best Practices, https://www.pingcap.com/article/boost-e-commerce-efficiency-with-tidb-case-studies-best-practices/
88. TiDB at Flipkart: Managing Data at E-Commerce Scale - YouTube, https://www.youtube.com/watch?v=GaXmLWVuqZo
89. SHOPLINE Slashes Cluster Costs by 50% with TiDB, https://www.pingcap.com/case-study/shopline-slash-cluster-cost-with-tidb/
90. High-Level Overview of TiDB: A Comprehensive Guide | by TechLatest.Net | Medium, https://medium.com/@techlatest.net/high-level-overview-of-tidb-a-comprehensive-guide-7bf4c58592af
91. Transforming Gaming with TiDB’s Scalable Database Solutions, https://www.pingcap.com/article/transforming-gaming-with-tidbs-scalable-database-solutions/
92. TiDB Customers, https://www.pingcap.com/customers/?industry=gaming
93. Why Capcom Chose TiDB Cloud as Its Scalable Managed Database for Online Games, https://www.pingcap.com/case-study/why-capcom-chose-tidb-cloud-as-its-scalable-managed-database-for-online-game/
94. TiDB Distributed Database Use Cases: Real-World Applications, https://www.pingcap.com/article/distributed-database-use-case/
95. AI 피처 스토어를 MongoDB와 Spring Cloud Stream으로 새롭게 구축한 이야기, https://techblog.lycorp.co.jp/ko/ai-feature-store-renewal-with-mongodb-and-spring-cloud-stream
96. pingcap/tidb: TiDB - the open-source, cloud-native, distributed SQL database designed for modern applications. - GitHub, https://github.com/pingcap/tidb
97. TiDB HTAP 살펴보기 - devkuma, https://www.devkuma.com/docs/tidb/explore-htap/
98. TiDB Labs로 분산 SQL 데이터베이스와 GenAI 앱 구축을 배워보세요, https://labs.tidb.io/ko